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ABSTRACT 

The Product Breakdown Structure is traditionally a method of 
identification of the products of a project in a tree structure. It 
is a tool used to assess, plan, document, and display the 
equipment requirements for a project. It is part of a product 
based planning technique, and attempts to break down all 
components of a project in as much detail as possible, so that 
nothing is overlooked. 

The PBS for ground systems at the Kennedy Space Center is 
being developed to encompass the traditional requirements 
including the alignment of facility, systems, and components to 
the organizational hierarchy. The Ground Operations 
Product Breakdown Structure is a hybrid in nature in that 
some aspects of a work breakdown structure will be 
incorporated and merged with the Architecture Concept of 
Operations, Master Subsystem List, customer interface, and 
assigned management responsibility. The Ground Operations 
Product Breakdown Structure needs to be able to identify the 
flexibility of support differing customers (internal and 
external) usage of ground support equipment within the 
Kennedy Space Center launch and processing complex. 

The development of the Product Breakdown Structure is an 
iterative activity initially documenting the organization 
hierarchy structure and relationships. The Product 
Breakdown Structure identifies the linkage between the 
customer program requirements, allocation of system 
resources, development of design goals, and identification 
logistics products. As the Product Breakdown Structure 
progresses the incorporation of the results of requirement 
planning for the customer occurs identifying facility needs and 
systems. The mature Product Breakdown Structure is 
baselined with a hierarchical drawing, the Product Breakdown 
Structure database, and an associated document identifying 
the verification of the data through the life cycle of the 
program/product line. 

This paper will document, demonstrate, and identify key 
aspects of the life cycle of a Hybrid Product Breakdown 
Structure. The purpose is to show how a project management 
and system engineering approach can be utilized for providing 
flexible customer service in an evolving manned space flight 
launch processing environment. 


1 WHAT IS A PRODUCT BREAKDOWN STRUCTURE 

The product breakdown structure is often described as a 
representation of tasks or measurement points tracked to the 


lowest level of the production lifecycle of the product 
creation. The PBS identifies the individual products 
necessary for the product. The PBS includes the hardware, 
software, and information items necessary to complete the 
project. The information items identified in the PBS can be 
essential documents, critical databases, and configuration 
drawings necessary to build or develop the product. 

The PBS is defined differently depending on the application 
or the organization developing the PBS. There is a project 
management application of the PBS and there is a system 
engineering application. Both develop the PBS at the same 
timeframe of a project. 

The PBS is developed during the developmental timeframe 
of the product. Specifically when the technical 
requirements are baselined. During the developmental 
timeframe the PBS is used to categorize the hardware, 
software, and informational products necessary as the 
development of the product proceeds. The evolution of the 
PBS through the life cycle of product development insures 
that the necessary products needed are identified and 
categorized. Each individual PBS identified product can 
have its own developmental process. Therefore, the PBS 
identifies individual production metrics necessary. 



Figure 1: Developmental Decomposition Process 


The individual PBS metrics provide traceability throughout 





the developmental lifecycle. In relation to the development 
of the technical requirement baseline other products are 
necessary to track requirements, verification, testing, and 
validation. The individual PBS identifies the item whether 
it is hardware, software, or informational necessary to 
baseline the production. 

In the PBS the responsibility for the individual hardware, 
software, and information product development needs to be 
identified. The organization responsible for the PBS 
identified metric provides traceability to performance of the 
task. The PBS as a result becomes the integration toll for 
the project identifying the responsible organization to 
deliver the identified metric (i.e. hardware, software, or 
informational) and all related data associated with it. 

The PBS becomes the single source for identification of 
hardware, software and the information products. As, a 
result is a top-down High level matrix of the products and 
organizations necessary to baseline the project. 

The PBS is not the Work Breakdown Structure (WBS) but 
the PBS is contained within the WBS. The WBS contains 
the financial accounting information and assigns budgetary 
goals for the organization [1]. 


2 HOW PBS RELATES TO PROJECT MANAGEMENT 

A project is a limited time endeavor utilized to build a 
specific product, perform a specific function, and have a 
specific goal. The implication is that a project has a specific 
beginning and a specific end. A project development 
structure used to build unique products defines the project 
scope. The project scope identifies the project justification, 
product, deliverables, and objectives. 



Figure 2: PBS as developed by Project 
Management 


The PBS is used to identify the project deliverables at a 
summary level. It provides the hardware, software, and 
information listing for the completion of the project. The 
PBS further is used to identify the organization responsible 


for the delivery of the hardware, software, and informational 
items. The scope of the deliverable needs to address by the 
project as well as, the integration of when the deliverable is 
required (its timeline) and the interface of the individual 
deliverable to the entire project. 

The PBS aids the project manager in the identification of the 
responsible organization and the deliverable necessary. The 
PBS is used in large and complex projects where a WBS has 
been identified to define budgetary applications [2]-[3]. 


3 HOW PBS RELATES TO SYSTEM ENGINEERING 

The development of the PBS in a system engineering 
development cycle is an iterative process that involves a 
connection between the concept of operations (ConOps) and 
requirements. The ConOps defines the scope of the system 
performance within the operational characteristics that it is 
being utilized. The ConOps is used (from a PBS outlook) to 
identify the subsystems necessary, how they interact, and 
system function to be performed in the process being 
defined. The requirements are derived from performance 
allocations, high level system interfaces, operations required 
to be performed, and the supportability needs of the 
subsystems. The iterative process develops the stakeholder 
requirements into operational concepts and the products (i.e. 
hardware, software, and informational) needs to produce the 
goal. As each of the system products are developed or 
changed the reflection of that change should enhance the 
PBS decomposition. Summarily, the PBS identifies the 
hardware, software, and informational needs to develop or 
process the product through the system based on the concept 
of operations or requirement defined by the customer. 


Functional 

Decomposition 


Figure 3: PBS as developed by System Engineering 



The PBS relationship to system engineering can be 
identified to three basic functional goals. 



• Translate top level requirements to functions 

• Identify functional interfaces into ConOps 

• Allocate functions in to the PBS 

For the system engineer the PBS functions as the conduit to 
transform requirements and ConOps to the responsible 
engineering level to deliver the hardware, software, and 
informational items [1, Sec. 4.0]. 


4 THE MERGER BETWEEN PROJECT ENGINEERING 

AND SYSTEM ENGINEERING USE OF THE PBS 

The project manager uses a PBS to identify the project 
deliverables by various groups, departments, or responsible 
parties. Therefore the PBS to the project manager is the 
function of the responsible group and the product. The 
project manager either within the WBS or external as the 
PBS identifies the responsible group and product (i.e., 
hardware, software, or informational). 

PBS PM = f(G, P) (1) 

Where: 

PBSp M is the product breakdown structure for project 
management. 

G is the various groups (i.e. Engineering, subcontracts) 

P is the product deliverable. 

The system engineer uses the PBS to identify how 
requirements and concept of operations relate to the system 
level functions. The system engineering identifies the PBS 
as it relates to the development of requirements and the 
concept of operations as well as the responsible group or 
organization to deliver the hardware, software, or 
informational product. 

PBS SE =f(R,C,G ) (2) 

Where: 

PBSse is the product breakdown structure for system 
engineering. 

R is Requirements 

C is the Concept of Operations (ConOps) 

G is the various groups (i.e. Engineering, organization) 

The merger of the two views of a PBS can be made to 
determine in a complex system first by, identification of 
various groups to provide deliverables, and second, to 
identify how operations relate to the individual systems. 

The intersection of PBS pm and PBS S e is becomes the 
engineering group responsible. 

Therefore: 

PBSpm n PBS se « /(G) (3) 


The common identifying function in both the project 
management and the system engineering application of the 
PBS is the engineering or responsible group for the delivery 
of the product or service [4]-[5]. 



The resultant PBS is based on the organization of the 
component product or service and its support to the project 
product description. The PBS provides the relationship 
from the lowest level product or service to the top level 
project product description as defined by the product owner. 



Figure 4: Composition of the PBS 


Level 1 provides the top level requirements development 
project product description. Level 1 is the product 
development goal. Level 2 defines the component products, 
service, or defined process supporting the level 1 
developmental goal. Component products are define the 
sub-component products or service required to complete the 
level 2 component product. 

5 GROUND SYSTEMS DEVLOPEMENT AND 
OPERATIONS APPROACH TO PBS 

In April of 2012 NASA established the Ground Systems 
Development and Operations (GSDO) program as the 
official program for the development of the ground systems 
and infrastructure for the Space Launch System (SLS), the 
Orion Multipurpose Crew Vehicle (MPCV), and future 
emerging users. GSDO program provides pre-launch 




processing, launch site support, and recovery resources. 
GSDO is center at the Kennedy Space Center (KSC) in 
Florida. GSDO is part of the Human Exploration and 
Operations Mission Directorate (HEO) and the Exploration 
Systems Development (ESD) which establishes the top level 
requirements and defines the mission objectives for GSDO 
[ 6 ], 



Figure 6: NASA Human Exploration Organization 


GSDO program has requirements established by the ESD. 
The requirements provided by the ESD define the 
operational goals for GSDO. In addition to the operational 
requirements the ESD has a set of technical process metrics 
to report. Cross program teams provide interaction between 
the three programs. 

The GSDO program operates as a project team with a 
systems engineering definition and is hybrid combination of 
both functional concepts. GSDO as a system engineering 
centered project has requirements to follow based on the 
customer (ESD). GSDO then establishes ConOps for the 
operation of the program based on the requirements. The 
individual subsystems utilized in the development of the 
GSDO PBS are identified in the Master Subsystem List 
(MSL). The definition of the individual subsystems is 
consistent with the assignment of the individual engineering 
teams. 

There is no specific document requirement for a Product 
Breakdown Structure (PBS) in the NASA guide for 
programs and project management it identifies a need for 
NASA program to establish a policy to apply disciplined, 
collaborative processes, and systems to identify, acquire, 
and control product data throughout the project life cycle. 
Also, there is no specific requirement identified by the 
NASA Chief engineering office to develop a PBS for the 
program. The PBS is discussed in detail in the NASA 
Systems Engineering handbook but as good systems 
engineering practice [7] [8]. 

5. 1 GSDO Program Project Organization Structure 

In order to manage the GSDO program a project 
management organizational structure was created to identify 
various levels of project reasonability. The large 
complexity of the project required that the responsibilities 


for the program be defined to separate levels. GSDO 
management has an analysis integration team (AIT) 
overseeing the various analysis and project processes. The 
Integrated Product Team (IPT) is divided into program areas 
needed to complete the project. Within the IPT are Element 
Integration Teams that are assigned to specific 
developmental products. These developmental products are 
identified to specific areas, responsibilities, may encompass 
a single production location, or provide services to many 
areas. 



Figure 7: GSDO Project Organization 


5.2 Work Breakdown Structure (WBS) 

The WBS as used in the GSDO program is used to define 
budget and allocations to the various GSDO projects and 
program levels. The WBS is utilized to approve 
developmental, operational, and logistical authorizations. 
The WBS is detailed to the IPT and is some cases the EIT 
level as identified by the IPT. 

5.3 Assets Capabilities Document (ACD) 

The ACD was developed to assist GSDO, SLS, MPCV, and 
Commercial Programs in the familiarization of capabilities 
provided by GSDO Program assets. It combines the high- 
level capabilities of the GSDO assets into one consolidated 
document including those required to support ground 
vehicle processing operations that are non-mission specific. 
In addition, the ACD provides references to the detailed 
drawings and figures where additional design data can be 
found [7]. 

5.2 Architectures and Concept of Operations Document 
(ACO) 

ACO Document describes the GSDO architecture in an 
operational context. This includes characteristics of the 
ground system, interfaces between GSDO and other 
programs, including commercial programs, nominal and 
contingency operational scenarios, and system performance 
expectations. Test flights for any vehicle will mirror this 
concept of operations as closely as possible [7]. 



5.3 Master subsystems List (MSL) 

This document establishes a Ground Systems Development 
and Operations (GSDO) Program list of the Kennedy Space 
Center (KSC) Subsystems that will receive requirements 
from the GSDO Elements. In addition, this document 
defines the design certification level which the subsystem is 
required to be verified. 

5.4 GSDO PBS Requirements 

The GSDO PBS requirements are aligned with the GSDO 
ACD, ACO, and MSL for the management responsibility 
and accountability. The GSDO PBS has been developed 
with the top level being defined by the needs of the project 
product description contained within the development of the 
requirements documents. 



Figure 9: GSDO PBS Supporting Documents 


6 GSDO PBS STRUCTURE 

The IPT represents the level 2 part of the program with the 
EIT responsible physical locations or facilities. The 
systems/subsystems contained within the respective location 
or facility is managed by the program through the EIT. The 
subsystems contain the equipment or components that 
encompass the subsystem. 

As requirements are established the EIT is responsible for 
establishing requirements for the individual subsystems’ to 
meet. The subsystems are defining the equipment or 
components that make-up the subsystem within the location 
or facility identified by the requirement. The PBS is the 
single point that identifies the System Engineering and 
Integration (SE&I) product that will provide this overall 
logical view of the interrelationship between equipment, 
subsystems, facilities, and EIT within the GSDO Program. 

The PBS is linked to the lowest level (configuration items, 
Line Replaceable Units (LRU), equipment, etc.) as defined 
by the responsible Design Engineering group. The PBS also 
links to data base products that document the association 
between the subsystem and the facility. This includes the 
facility to which the subsystem is located and the EIT 


responsible for the facility. The linkages to Design/CAD 
Data, requirements data, and risk data, manufacturing data - 
work instructions, operations, and test data will be identified 
at the top drawing level. The GSDO PBS by providing this 
linkage to will associate subsystem design or sustaining 
engineering with the facility and therefore the product 
structure required for the project. 


Facility 

T 



Figure 8: GSDO PBS Structure 


The various other related activities such as Verification & 
Validation, Logistics, Ground Operations Planning & 
Development (GOPD), Configuration Management, and 
Work Order Control can use the PBS as a baseline 
document to identify program requirements for a specific 
location as managed by the EIT. The use of a single top 
level drawing as identified by the PBS would provide a 
single resource point to track and document the subsystems 
throughout the life cycle of the program. 

7 GSDO PBS DEVELOPMENT 

The GSDO PBS development activity for the System 
Requirements Review (SRR) was to define and document 
the hierarchical of the structure of the PBS. As GSDO 
progresses to the Preliminary Design Review (PDR) the 
PBS it will incorporate the requirement planning for the 
subsystems and identify the component or equipment that 
make-up the respective subsystems by the top level drawing. 
At the GSDO Critical Design Review (CDR) the PBS will 
be baselined with the top level drawing, database, or an 
associated document identifying the verification of the data 
through with the life cycle of the program/product line. 

8 GSDO PBS SUMMARY AND CONCLUSION 
Once the PBS is complete; it will be a useful tool for 




subsystem 


subsystem 





communicating what needs to be built. It also provides a 
linkage between the program, design, and logistics products. 
The IPT, EIT, and Engineering, will take advantage of 
logical organization and access to information. The PBS 
will show the location capability, subsystems located in the 
location, and the supporting subsystem top level drawing. 
The GSDO PBS provides traceable product information 
(e.g., data, documents) throughout life-cycle (i.e., design, 
manufacturing, verification and validation, 
assembly/integration, launch). As an operations tool the 
PBS will vary with missions and will be the single source to 
quickly locate subsystem design information. 

REFERENCES 

1 . NASA Systems Engineering Handbook, NASA Special 
Publication SP-2007-6105 rev 1, 2007 

2. IEEE Guide Adoption of PMI Standard: A Guide to the 
Project Management Body of Knowledge, IEEE 
Standard 1490, 2003 

3. T.C. Belanger. 1997 Successful Project Management, 
American Management Association. 

4. The National Shipbuilding Research Program: Product 
Work Breakdown Structure, U.S. Department of 
Transportation Maritime Administration NSRP-0164, 
1982 

5. C.E. Ebeling. 2005. An Introduction to Reliability and 
Maintainability Engineering. Waveland Press 

6. “Program/Project Formulation Authorization 
Document: Ground Systems Development and 
Operations Program”, NASA, unpublished. 

7. NASA Program and Project Management Process and 
Requirements, NASA Procedures and Guidelines NPG 
7120.5B, 2007 

8. NASA Systems Engineering Processes and 
Requirements, NASA Procedural Requirements NPR 
7123. 1A, 2012 


(IEEE) Industrial Application Society (IAS) and Reliability 
Society. He is also a member of American Institute of 
Aeronautics and Astronautics (AIAA), American Society 
for Engineering Management (ASEM), Institute for 
Operations Research and the Management Sciences 
(INFORMS), and the American Society for Quality (ASQ) 
Reliability Society. 

Robert J. Henry 
Bldg. M7-0355 
MS: LX-S2 

Kennedy Space Center, FL, 32899, USA 

e-mail: Robert.j.henry@nasa.gov 

Robert J. Henry received his Master of Business 
Administration (M.B.A.) from Florida Institute of 
Technology and Bachelor’s degree from the University of 
Illinois at Chicago. Robert is currently a Systems Engineer 
with National Aeronautics and Space Administration 
(NASA) working in the Program Integration Division of the 
Ground Systems Development and Operations (GSDO) 
Program at KSC, FL. Previously he has held positions with 
NASA as Mission Assurance Manager and Vehicle Systems 
Engineer for the Launch Services Program (LSP) at KSC. 


BIOGRAPHIES 


MarkW. Monaghan 
Bldg. M7-0355 
MS: LX-SAIC 

Kennedy Space Center, FL, 32899, USA 

e-mail: mark.w.monaghan@nasa.gov 

Mark W. Monaghan received his Ph.D. in Applied 
Decision Science from Walden University, a Master’s 
degree from Embry-Riddle Aeronautical University and 
Bachelor’s degree from the University of Minnesota-Duluth. 
Mark is a Reliability Engineer with SAIC at NASA 
Kennedy Space Center, FL. As a part of the Kennedy 
Space Center Reliability Maintainability and Availability 
(RMA) team, Dr. Monaghan works with multiple 
engineering teams to evaluate and increase the operational 
and inherent availability of the systems. He is a senior 
member of Institute of Electrical and Electronic Engineers 


